Add sign-public-ecr-image job to release workflow#1362
Add sign-public-ecr-image job to release workflow#1362wangzlei merged 1 commit intoaws-observability:mainfrom
Conversation
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1362 +/- ##
=============================================
- Coverage 85.71% 69.39% -16.33%
- Complexity 19 704 +685
=============================================
Files 3 63 +60
Lines 49 3437 +3388
Branches 5 487 +482
=============================================
+ Hits 42 2385 +2343
- Misses 3 861 +858
- Partials 4 191 +187 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review Summary
I reviewed the sign-public-ecr-image job added to the release workflow. Overall the approach is sound and consistent with the existing signing pattern in publish-layer-prod. I found 2 issues worth addressing (1 security, 1 bug) and 1 suggestion. See inline comments below.
| # Install notation CLI with AWS Signer plugin | ||
| - name: Install notation CLI with AWS Signer plugin | ||
| run: | | ||
| curl -Lo aws-signer-notation-cli_amd64.deb https://d2hvyiie56hcat.cloudfront.net/linux/amd64/installer/deb/latest/aws-signer-notation-cli_amd64.deb |
There was a problem hiding this comment.
Security: Binary downloaded without integrity verification
The notation CLI .deb package is downloaded from a CloudFront URL using the mutable latest tag, with no checksum or signature verification before installing via dpkg. If the CDN or distribution endpoint is compromised, a malicious binary would be silently installed and then used to sign your release images.
Consider pinning to a specific version and verifying its SHA256 checksum, e.g.:
run: |
NOTATION_VERSION="1.3.0" # pin to a known version
NOTATION_SHA256="<expected-sha256>"
curl -Lo aws-signer-notation-cli_amd64.deb \
"https://d2hvyiie56hcat.cloudfront.net/linux/amd64/installer/deb/${NOTATION_VERSION}/aws-signer-notation-cli_amd64.deb"
echo "${NOTATION_SHA256} aws-signer-notation-cli_amd64.deb" | sha256sum -c -
sudo dpkg -i aws-signer-notation-cli_amd64.debThis is the same supply-chain hardening principle behind pinning GitHub Actions to commit SHAs (which this workflow already does correctly).
| - name: Query ECR Signing Profile ARN | ||
| id: ecr-signing-profile | ||
| run: | | ||
| PROFILE_ARN=$(aws signer list-signing-profiles --region ${{ env.AWS_PUBLIC_ECR_REGION }} --query "profiles[?profileName=='ADOTECRSigningProfile'].arn" --output text 2>/dev/null) |
There was a problem hiding this comment.
Bug: stderr suppression masks real AWS CLI errors. Redirecting stderr to /dev/null on the aws signer list-signing-profiles call (2>/dev/null) means that real failures like authentication errors, network timeouts, permission denied, and throttling are silently suppressed and treated identically to profile-not-found. The job would succeed without signing even when the profile exists but credentials are misconfigured. Consider removing 2>/dev/null and checking the exit code explicitly. If the AWS CLI call fails, the step should fail rather than silently skip. You could also use workflow warning annotations when the profile genuinely does not exist, so operators have visibility into skipped signing during releases. Note: the same 2>/dev/null pattern exists in the publish-layer-prod job (line 305) but is less critical there since that step uses continue-on-error: true.
| echo "profile_arn=$PROFILE_ARN" >> $GITHUB_OUTPUT | ||
| echo "Found ECR signing profile: $PROFILE_ARN" | ||
| else | ||
| echo "ECR signing profile 'ADOTECRSigningProfile' not found" |
There was a problem hiding this comment.
Suggestion: Silent success when signing profile is missing may be too permissive for a release workflow. When the profile is not found, this exits 0 and subsequent steps are skipped via conditionals - the entire job reports success without any image being signed. For a release pipeline, consider making this a hard failure (exit 1) or at minimum emitting a GitHub Actions warning annotation so that release operators are aware signing was skipped. A release that ships unsigned images when signing was intended could be a compliance gap.
3 participants
Summary
Backports the
sign-public-ecr-imagejob from aws-otel-python-instrumentation release/v0.14.x to the Java instrumentation release workflow.Changes
Added
sign-public-ecr-imagejob in.github/workflows/release-build.ymlthat:AWS_ASSUME_ROLE_ARN_RELEASEADOTECRSigningProfilesigning profile ARN (gracefully skips if not found)PUBLIC_REPOSITORY:v$VERSIONThe job runs after
publish-sdkwhich pushes the multi-arch image to public ECR.